Hi,

Here are my comments on draft-ietf-xcon-common-data-model-05. They  
are mostly editorial in nature.

Thanks!

Ben.

---------

General:

I share Gonzalo's comment about the scope of the data model being  
unclear. In particular, is it the goal of this document to define how  
the contents of a conference object affect behavior of various  
devices? If so, then there is a notable lack of normative language to  
that effect throughout the document.

Many element types can be used  in different contexts (i.e. as  
children of different parents), and if I understand correctly, their  
meaning may be different depending on the context in which they are  
used. I personally don't feel like I fully understand all of these  
after multiple detailed reads of the document. It might help to have  
more examples. Rather than whole documents, it might be useful to put  
in document fragment examples illustrating specific usages.

Section 4 is inconsistent in how it presents elements. In some cases,  
an element and its children are all defined in the same section. In  
others, there is a section for each. Furthermore, it requires some  
reading between the lines to understand when this document is  
defining an element vs. incorporating an element defined elsewhere.  
This is explicit in some cases, but not consistent. My personal  
preference would be to give each element its own section, and use a  
common list-oriented format for things like contexts, potential  
children, where the element is defined, cardinality, etc. But the  
important thing is consistency.


Specific comments:

Section 3.2 Paragraph 2:

Why do we need normative statements about what privileges should be  
associated with each role?

Section 4 Paragraph 1:

I assume a conference object document and a conference object data  
model document are the same thing? It would be helpful to be  
consistent with the terminology.

Paragraph 2:

Need a reference for the definition of XCON-URI

Paragraph 5:

(Personal pet peeve nit) I find constructs of the form "...defined in  
[1]" difficult to follow. The construct "... defined in RFC XXXX[1]"  
is better. This is partly to save the reader from constant flipping  
back to the end-notes. But in general the end-note reference is  
parenthetical, and the sentence should still make sense if the  
reference is completely removed.

Diagram:
Is it possible to give this a referenceable "figure" number? Also, it  
would be helpful if the diagram could show cardinality somehow.

Section 4.1: Paragraph 1.

The section gives brief descriptions of each child elements, but the  
real descriptions occur in the following sections. It would be better  
to just mention the child elements by name, and refer to the sections  
for each. Repeating the same info twice is likely to create  
inconsistencies as the document evolves.

4.1.1

This is an example of a section that defines child elements in the  
same section as its parents. I personally think this would be easier  
for readers if each element got its own section. But in any case, it  
should be consistent from section to section.

4.1.5.1 Paragraph 1:

What does it mean for an element to contain controls? How is the  
element actually used? Assuming this is described elsewhere, can we  
put in a reference to that description

4.1.5.1.4.

Entire Section:

I find it naive to believe we can specify all useful or likely  
layouts in advance. Wouldn't it make more sense to describe these in  
terms of what the focus has to do rather than how a client displays  
things? (I don't mean to question wg concensus if this has already  
been discussed to death)

Paragraph 2:

I find no reference to a <layout> element elsewhere. Should this be  
<video-layout>

4.5

I am really confused on how all the <users> sub-elements fit  
together. For example, what would it mean to have <join- 
handling>allow</join-handling>, an <allowed-users-list>, and a <user>  
element in the same <users> parent? Some more example scenarios would  
help.


5:

I am not familiar with RELAX NG. Hopefully an expert in this is  
reviewing the document?

7. Example

<conf-uris> contains a child element of <SIP>. The text said that we  
reuse <entries> for SIP URIs in this context for backwards  
compatibility with the SIP conference model.

Same for <host-info>.

8. Security Considerations

This section seems rather lightweight. The text motivates why we care  
about authentication, but does not provide motivation for  
confidentiality and integrity. I suspect a discussion of possible  
privacy issues may be in order. Also, I assume these documents may be  
stored and cached, as well as transferred, so some considerations  
about whether it is okay to just leave them laying around might be  
worth having.











_______________________________________________
XCON mailing list
XCON@ietf.org
https://www1.ietf.org/mailman/listinfo/xcon